Since it's memoized it's nice to limit things before the ||=.

We need to be careful here--there's the potential for a naming conflict. If two EG extension libraries both defined an extension module for SchemaArtifactManager (say, elasticgraph-json_ingestion and elasticgraph-proto-ingestion), and they both defined a method named format_deprecated_elements, they could run into a collision. Each extension would work correctly in isolation but would potentially be buggy when both extensions were used.

That's unlikely to happen for any method that has json_schema in the name...but format_deprecated_elements, missing_field_error_for, missing_type_error_for, missing_necessary_field_error_for, and files_noun_phrase have pretty generic names--I can imagine any extension defining methods with those names and colliding.

This is similar to my comment from last review. Ideally the methods defined on an extension module all fall into one of two buckets:

1. They offer a new public API
2. They hook into/override existing methods to customize behavior

I'm not as worried about collisions in these cases. Public APIs are thoughtfully named and unlikely to collide; hooking into existing methods is performed in a composable way with super.

There are two general approaches I'd recommend here:

1. Instead of an extension module, wrap with a DelegateClass class, like we did with elasticgraph-json_ingestion/lib/elastic_graph/json_ingestion/schema_definition/indexing/field_type/enum.rb in Add JSON ingestion indexing extensions #1204. However, it won't work here because wrapping doesn't let you hook in and override artifacts_from_schema_def (there's no way to intercept that via a wrapping class because it's an internal private method).
2. Keep the extension module for the methods which fit the criteria above. For everything else, move it into a separate class or module which you delegate to.

I think the 2nd option will work best here but the 1st option may come in handy in other cases.

(Tangentially, I have a similar concern about your results_extension.rb module as well--as it defines so many private methods----but there all the methods have json_schema in the name so a naming collision is less likely. If you get a hankering to give it the same treatment, feel free, but also fine to leave it!).

Have you removed this in a follow up PR? (If so can you link it)?